1. Field of the Invention
This invention relates generally to computational models of dynamic processes within living organisms, and more particularly, to systems and methods for enabling generation of computational models of drug behavior.
2. Description of Related Art
Information regarding the behavior of drugs and diseases in the body of a living organism is needed for many purposes in biological science and industry. Generally, this information gives rise to two interrelated disciplines: pharmacokinetics, which is the study of the processes by which a drug is absorbed, distributed, metabolized and eliminated by the body, and pharmacodynamics, which is the study of the action or effects of drugs on living organisms.
Pharmacokinetics and pharmacodynamics are combined to study the efficacy of drugs and the progression of diseases, through the use of computational models. Such computational models are also commonly referred to as drug models or input/output models. Typically, these computational models are stored as software subroutines in a high level language, such as Fortran, for use in a variety of applications. Two applications in particular require these computational models: model fitting of clinical data, and simulation of clinical trials.
The traditional approach to generating these computational models is labor intensive and prone to extensive delays caused by human error. For example, in the case of generating a drug model, typically, a researcher will review all the information available concerning the way in which the drug behaves in the body of interest. In some cases, the researcher might also draw some rough sketches of compartments representing the various organs in the body and showing the flow of the drug through those organs. Then the researcher must figure out the differential equations that model that drug behavior, or alternatively, solve the differential equations using closed form solutions and determine the exponential equations. Finally, the equations must be translated into software, which in turn must be debugged.
Whenever software is written, human error and oversight invariably introduce bugs. Thus debugging of software is a necessary step, which can be tedious and time consuming. Further, the software debugging process is usually not complete until the researcher uses the software in an existing application and analyses the results to see if they make sense. These problems with drug model generation are exacerbated by the fact that many researchers are trained in the life sciences and are not necessarily experts at coding software. Using a trained' computer programmer to work with the researcher may introduce needed coding expertise, but can also compound the problem by introducing a communication step to the process, which presents more opportunities for human error.
An early attempt to address the problem of researchers' lack of coding experience was the Advanced Continuous Simulation Language (ACSL). ACSL is a simulation language that allows a researcher to write differential equations, which are then converted into Fortan for insertion into a simulation program. While ACSL was an improvement, the language was not substantially different from the Fortran language itself, thus a researcher still needed knowledge of how Fortran programming works. Moreover, ACSL did not address any of the other significant problems, such as the difficulty of model verification before a simulation has been run.
Graphical drug model builders have also been created. For example, Pharsight Trial Designer 1.2, available from Pharsight Corporation, 800 West El Camino Real, Suite 200, Mountain View, Calif. 94040, includes a graphical model builder component, which allows a researcher to build a drug model using graphical blocks. Once the drug model is completed, the software generates code for use in trial simulation. The generated code implements the appropriate differential equations. However, when errors are made in the construction of the drug model, these errors may not be discovered until after a drug trial simulation is completed.
A common error in drug model construction is a “units” error. The researcher may build one part of the drug model using constants in one set of units, and another part of the drug model using constants of entirely different units. If the data entered into such systems is not in internally consistent quantitative units, e.g., units of amount, units of time, units of volume, units of flow, etc., this can lead to substantial errors and inaccuracies in the final computational model. The researcher frequently only discovers these errors after the trial simulation is run, and the researcher compares the products of the drug model with expectations. Since drug trial simulation frequently involves a large amount .of processor time, this approach is inefficient at accelerating the drug model creation process.
In addition to graphical model builders directed specifically to drug model generation, other graphical model builders have also been created. For example, Stella 6.0, available from High Performance Systems, Inc., 45 Lyme Road, Suite 300, Hanover, N.H. 03755-1221, is software designed to render and test mental models of everything from “how a bowl of soup cools to how a galaxy expands . . . and everything in between.” See http://www.hps-inc.com/edu/stella/stella.htm. While these types of software tools may be used to build drug models, their lack of focus on a particular problem set makes them less effective in the pharmacological context.
Moreover, when errors are made in the construction of a model, these errors are typically not found until after a simulation is completed. In the context of unit checking, Stella 6.0 allows a user to specify units for terms of equations and check for consistent units by pressing a button. However, Stella does not actively monitor units or handle the interrelation of multiple unit types such that, for example, milligrams are automatically converted into grams when necessary. Thus, unit checking with Stella is time consuming and significant unit errors are still possible. For simple simulations this is less of a concern, but for drug trial simulations, these errors can cause extensive delays in drug model verification.